Configuring Classification Rules

The Classification table lets you configure up to 1,500 Classification rules. A Classification rule classifies incoming SIP dialog-initiating requests (e.g., INVITE messages) to a "source" IP Group. The source IP Group is the SIP entity that sent the SIP dialog request. Once classified, the device uses the IP Group to process the call (manipulation and routing).

You can also use the Classification table for employing SIP-level access control for successfully classified calls, by configuring Classification rules with whitelist and blacklist settings. If a Classification rule is configured as a whitelist ("Allow"), the device accepts the SIP dialog and processes the call. If the Classification rule is configured as a blacklist ("Deny"), the device rejects the SIP dialog.

Configuration of Classification rules includes two areas:

■ Match: Defines the matching characteristics of the incoming IP call (e.g., source SIP Interface and IP address). Classification is primarily based on the SIP Interface as the matching characteristics on which the incoming dialog is received. As Classification rules must first be assigned an SRD, the SIP Interface is one that belongs to the SRD. Therefore, Classification rules are configured per SRD, where multiple SIP Interfaces can be used as matching characteristics. However, as multiple SRDs are relevant only for multi-tenant deployments, for most deployments only a single SRD is required. As the device provides a default SRD ("Default_SRD"), where only one SRD is required, the device automatically assigns it to the Classification rule.
■ Action: Defines the action that is done if the incoming call matches the characteristics of the rule (i.e., classifies the call to the specified IP Group).

The device searches the table from top to bottom for the first rule that matches the characteristics of the incoming call. If it finds a matching rule, it classifies the call to the IP Group configured for that rule. If you are using source tags to classify incoming calls to IP Groups, then once the device locates a matching rule (including a match for the source tag), the device searches the IP Groups table for an IP Group with the matching tag. For more information on classification based on tags, see Configuring Classification Based on Tags.

Configure stricter classification rules higher up in the table than less strict rules to ensure incoming dialogs are classified to the desired IP Group. Strict refers to the number of matching characteristics configured for the rule. For example, a rule configured with source host name and destination host name as matching characteristics is stricter than a rule configured with only source host name. If the rule configured with only source host name appears higher up in the table, the device ("erroneously") uses the rule to classify incoming dialogs matching this source host name (even if they also match the rule appearing lower down in the table configured with the destination host name as well).

If the device doesn't find a matching rule (i.e., classification fails), the device rejects or allows the call depending on configuration. For more information, see Configuring Action for Classification Failure.

The Classification table is used to classify incoming SIP dialog-initiating requests only if the following classification stages fail:

1. Classification Stage 1 - Classification by Users Registration Database: The device searches its users registration database to check whether the incoming SIP dialog-initiating request arrived from a registered user. The device searches the database for a user that matches the address-of-record (AOR) and Contact of the incoming SIP message:
● Compares the SIP Contact header to the contact value in the database.
● Compares the URL in the SIP P-Asserted-Identity/From header to the registered AOR in the database.

If the device finds a matching registered user, it classifies the user to the IP Group that is associated with the user in the database.

If this classification stage fails, the device proceeds to classification by Proxy Set (see below).

You can enable or disable classification by the device's users registration database per SIP Interface. For more information, see the 'Classify By Registration DB' parameter in the SIP Interfaces table, as described in Configuring SIP Interfaces.

2. Classification Stage 2 - Classification by Proxy Set: If classification of the incoming SIP dialog-initiating request by users registration database fails (see above), the device performs classification based on Proxy Set. This classification is applicable only to Server-type IP Groups and is done only if you've enabled classification by Proxy Set ('Classify By Proxy Set' parameter in the IP Groups table, as described in Configuring IP Groups).

By default, the device checks if the source IP address (ISO Layer 3) of the incoming SIP dialog message (e.g., INVITE) matches an IP address in the Proxy Set that is associated with the IP Group (assigned in the IP Groups table). If the Proxy Set is configured with a host name, the device checks if the source IP address matches one of the dynamically DNS-resolved IP addresses. If such a Proxy Set exists, the device classifies the SIP dialog to the IP Group associated with the Proxy Set.

You can also configure Classification by Proxy Set whereby the device checks if the IP address in the SIP Contact header of the incoming SIP dialog matches an IP address in the Proxy Set that is associated with the IP Group. If the header contains a SIP URI that has an IP address (not hostname) in the host part and it matches an IP address in the Proxy Set, the call is classified to the IP Group. This mode is useful, for example, when the source IP address is an internal address.

The IP address to use (source IP address or IP address in Contact header) of the incoming SIP dialog for classification by Proxy Set is configured by the global parameter, 'Classify By Proxy Set Mode' (Setup menu > Signaling & Media tab > SIP Definitions folder > SIP Definitions General Settings), as shown below. When configured to Both, the device first checks if the source IP address matches an IP address in the Proxy Set. Only if there is no match, does it check if the IP address in the SIP Contact header matches an IP address in the Proxy Set.

If more than one Proxy Set is configured with the same IP address and associated with the same SIP Interface, the device may classify and route the SIP dialog to an incorrect IP Group. In such a scenario, a warning is generated in the syslog message. However, if some Proxy Sets are configured with the same IP address but different ports (e.g., 10.1.1.1:5060 and 10.1.1.1:5070) and the 'Classification Input' parameter is configured to IP Address, Port & Transport Type, classification (based on IP address and port combination) to the correct IP Group is achieved. Therefore, when classification is by Proxy Set, pay attention to the configured IP addresses and the 'Classification Input' parameter of your Proxy Sets. When more than one Proxy Set is configured with the same IP address, the device selects the matching Proxy Set in the following precedence order:

a. Selects the Proxy Set whose IP address, port, and transport type match the source of the incoming dialog.
b. If no match is found for a), it selects the Proxy Set whose IP address and transport type match the source of the incoming dialog (if the 'Classification Input' parameter is configured to IP Address Only).
c. If no match is found for b), it selects the Proxy Set whose IP address match the source of the incoming dialog (if the 'Classification Input' parameter is configured to IP Address Only).

If classification by Proxy Set fails (or classification by Proxy Set is disabled), the device proceeds to classification by the Classification table, as described in this section

● For security, it is recommended to classify SIP dialogs based on Proxy Set only if the IP address of the Server-type IP Group is unknown. In other words, if the Proxy Set associated with the IP Group is configured with an FQDN. In such cases, the device classifies incoming SIP dialogs to the IP Group based on the DNS-resolved IP address. If the IP address is known, it is recommended to use a Classification rule instead (and disable the Classify by Proxy Set feature), where the rule is configured with not only the IP address, but also with SIP message characteristics to increase the strictness of the classification process. The reason for preferring classification based on Proxy Set when the IP address is unknown is that IP address forgery (commonly known as IP spoofing) is more difficult than malicious SIP message tampering and therefore, using a Classification rule without an IP address offers a weaker form of security. When classification is based on Proxy Set, the Classification table for the specific IP Group is ignored.
● If multiple IP Groups are associated with the same Proxy Set, use Classification rules to classify the incoming dialogs to the IP Groups (do not use the Classify by Proxy Set feature).
● When using the Classification table for classification instead of by Proxy Set, it's recommended to enable the 'Validate Source IP' parameter in the IP Groups table. This setting verifies that the request was sent from one of the IP addresses (including DNS-resolved IP addresses) of the associated Proxy Set.
● The device saves incoming SIP REGISTER messages in its registration database. If the REGISTER message is received from a User-type IP Group, the device sends the message to the configured destination.

The flowchart below illustrates the classification process:

The following procedure describes how to configure Classification rules through the Web interface. You can also configure it through ini file [Classification] or CLI (configure voip > sbc classification).

➢ To configure a Classification rule:
1. Open the Classification table (Setup menu > Signaling & Media tab > SBC folder > Classification Table).
2. Click New; the following dialog box appears (cropped for convenience):

3. Configure the Classification rule according to the parameters described in the table below.
4. Click Apply.

Classification Table Parameter Descriptions

Parameter

Description

'SRD'

srd-name

[SRDName]

Assigns an SRD to the rule as a matching characteristic for the incoming SIP dialog.

If only one SRD is configured in the SRDs table, the SRD is assigned to the rule by default. If multiple SRDs are configured in the SRDs table, no value is assigned.

To configure SRDs, see Configuring SRDs.

Note: The parameter is mandatory.

Match

'Index'

[Index]

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

'Name'

classification-name

[ClassificationName]

Defines a descriptive name, which is used when associating the row in other tables.

The valid value is a string of up to 40 characters. By default, no name is defined.

Note:

■ Configure each row with a unique name.
■ The parameter value can't be configured with the character string "any" (upper or lower case).

'Source SIP Interface'

src-sip-interface-name

[SrcSIPInterfaceName]

Assigns a SIP Interface to the rule as a matching characteristic for the incoming SIP dialog.

The default is Any (i.e., all SIP Interfaces belonging to the SRD assigned to the rule).

Note: The SIP Interface must belong to the SRD assigned to the rule (see the 'SRD' parameter in the table).

'Source IP Address'

src-ip-address

[SrcAddress]

Defines a source IP address as a matching characteristic for the incoming SIP dialog.

The valid value is an IP address in dotted-decimal notation. In addition, the following wildcards can be used:

■ "x" wildcard: represents single digits. For example, 10.8.8.xx represents all addresses between 10.8.8.10 and 10.8.8.99.
■ Asterisk (*) wildcard: represents any number between 0 and 255. For example, 10.8.8.* represents all addresses between 10.8.8.0 and 10.8.8.255.

By default, no value is defined (i.e., any source IP address is accepted).

Note:

■ The parameter is applicable only to Server-type IP Groups.
■ If the IP address is unknown (i.e., configured for the associated Proxy Set as an FQDN), it is recommended to classify incoming dialogs based on Proxy Set (instead of using a Classification rule). For more information on classification by Proxy Set or by Classification rule, see the note bulletin in the beginning of this section.

'Source Transport Type'

src-transport-type

[SrcTransportType]

Defines the source transport type as a matching characteristic for the incoming SIP dialog.

■ [-1] Any = (Default) All transport types
■ [0] UDP
■ [1] TCP
■ [2] TLS
■ [3] SCTP

'Source Port'

src-port

[SrcPort]

Defines the source port number as a matching characteristic for the incoming SIP dialog.

By default, no value is defined.

'Source Username Pattern'

src-user-name-pattern

[SrcUsernamePrefix]

Defines the source URI user part as a matching characteristic for the incoming SIP dialog. The URI is typically located in the SIP From header. However, you can configure the SIP header from where the device obtains the source URI, in the IP Groups table ('Source URI Input' parameter). For more information on how the device obtains the URI, see SIP Dialog Initiation Process.

You can use special patterns (notations) to denote the user part. For example, if you want to match this rule to user parts whose last four digits (i.e., suffix) are 4 followed by any three digits (e.g., 4008), then configure this parameter to "(4xxx)", without the quotation marks. For available patterns, see Dialing Plan Notation for Routing and Manipulation.

The valid value is a string of up to 60 characters. The default is the asterisk (*) symbol, meaning any source user part.

Note: For REGISTER requests, the source URI is obtained from the To header.

'Source Host'

src-host

[SrcHost]

Defines the prefix of the source URI host name as a matching characteristic for the incoming SIP dialog.

The URI is typically located in the SIP From header. However, you can configure the SIP header from where the device obtains the source URI, in the IP Groups table ('Source URI Input' parameter). For more information on how the device obtains this URI, see Call Processing of SIP Dialog Requests.

The default is the asterisk (*) symbol, which represents any source host prefix.

Note: For REGISTER requests, the source URI is obtained from the To header.

'Destination Username Pattern'

dst-user-name-pattern

[DestUsernamePrefix]

Defines the destination Request-URI user part as a matching characteristic for the incoming SIP dialog.

You can use special patterns (notations) to denote the user part. For example, if you want to match this rule to user parts whose last four digits (i.e., suffix) are 4 followed by any three digits (e.g., 4008), then configure this parameter to "(4xxx)", without the quotation marks. For available patterns, see Dialing Plan Notation for Routing and Manipulation.

The valid value is a string of up to 60 characters. The default is the asterisk (*) symbol, meaning any destination user part.

'Destination Host'

dst-host

[DestHost]

Defines the prefix of the destination Request-URI host name as a matching characteristic for the incoming SIP dialog.

The default is the asterisk (*) symbol, which represents any destination host prefix.

'Message Condition'

message-condition-name

[MessageConditionName]

Assigns a Message Condition rule to the Classification rule as a matching characteristic for the incoming SIP dialog.

By default, no value is defined.

To configure Message Condition rules, see Configuring Message Condition Rules.

'TLS Remote Subject Name'

tls-remote-subject-name

[TLSRemoteSubjectName]

Defines the Subject Name of the TLS certificate used for the TLS connection upon which the SIP dialog message is received, as a matching characteristic for the incoming SIP dialog.

If there is no match and the SAN is marked as "critical", classification to the specific rule fails. If there is no match but the Subject Alternative Name (SAN) isn't marked as "critical", the device checks if the configured value matches the certificate's Common Name (CN).

By default, no value is defined.

Note:

■ For classification of incoming SIP dialogs by TLS certificate Subject Name, make sure that you also do the following:
✔ Enable TLS mutual authentication globally using the [SIPSRequireClientCertificate] parameter, or per SIP Interface using the 'TLS Mutual Authentication' parameter.
✔ Configure the Proxy Set's 'Peer Host Name Verification Mode' parameter to Disable (prevents TLS connections closing before the Classification stage).
■ If you are classifying incoming SIP dialogs by Proxy Set (configured by the 'Classify By Proxy Set' parameter in the IP Groups table), classification by certificate Subject Name isn't supported and therefore, this parameter isn't applicable. For classification by Proxy Set, enable the Proxy Set's 'Peer Host Name Verification Mode' parameter (see Configuring Proxy Sets).
■ A certificate may include multiple SAN types (e.g., Email, DNS, URI, and IP). The only SAN types that the device compares for matching are DNS and IP.

Action

'Action Type'

action-type

[ActionType]

Defines a whitelist or blacklist for the matched incoming SIP dialog.

■ [0] Deny = Blocks incoming SIP dialogs that match the characteristics of the rule (blacklist).
■ [1] Allow = (Default) Allows incoming SIP dialogs that match the characteristics of the rule (whitelist) and assigns it to the associated IP Group.

'Destination Routing Policy'

dest-routing-policy

[DestRoutingPolicy]

Assigns a Routing Policy to the matched incoming SIP dialog.

The assigned Routing Policy overrides the Routing Policy assigned to the SRD (in the SRDs table). The option to assign Routing Policies to Classification rules is useful in deployments requiring different routing and manipulation rules for specific calls pertaining to the same SRD. In such scenarios, you need to configure multiple Classification rules for the same SRD, where for some rules no Routing Policy is assigned (i.e., the SRD's assigned Routing Policy is used) while for others a different Routing Policy is specified to override the SRD's assigned Routing Policy.

By default, no value is defined.

To configure Routing Policies, see Configuring SBC Routing Policy Rules.

'IP Group Selection'

ip-group-selection

[IPGroupSelection]

 

Defines how the incoming SIP dialog is classified to an IP Group.

■ [0] Source IP Group = (Default) The SIP dialog is classified to the IP Group that is specified in the 'Source IP Group' parameter (see below).
■ [1] Tagged IP Group = The SIP dialog is classified to an IP Group based on source tag, which is specified in the 'IP Group Tag Name' parameter (see below). For more information on Classification of incoming SIP dialogs to IP Groups using tags, see Configuring Classification Based on Tags.

'Source IP Group'

src-ip-group-name

[SrcIPGroupName]

Assigns an IP Group to the matched incoming SIP dialog.

By default, no value is defined.

To configure IP Groups, see Configuring IP Groups.

Note:

■ The parameter is applicable only if you configure the 'IP Group Selection' parameter to Source IP Group.
■ The IP Group must be associated with the assigned SRD (see the 'SRD' parameter in the table).

'IP Group Tag Name'

ip-group-tag-name

[IpGroupTagName]

Defines the source tag of the incoming SIP dialog. The tag is used for classifying the SIP dialog to an IP Group. The tag is obtained from the Call Setup Rule that is associated with the SIP Interface on which the dialog is received.

The valid value is a string of up to 255 characters. The default value is "default" (without quotation marks), which must be used when the resultant tag from the Call Setup Rule is only a value (e.g., "Ireland"). If the resultant tag is a name=value (e.g., "Country=Ireland"), then configure the parameter with the name only (e.g., "Country"). Only one tag name can be configured.

For more information on Classification of incoming SIP dialogs to IP Groups using tags, see Configuring Classification Based on Tags.

Note: The parameter is applicable only if you configure the 'IP Group Selection' parameter to Tagged IP Group.

'IP Profile'

ip-profile-id

[IpProfileName]

Assigns an IP Profile to the matched incoming SIP dialog.

The assigned IP Profile overrides the IP Profile assigned to the IP Group (in the IP Groups table) to which the SIP dialog is classified. Therefore, assigning an IP Profile during classification allows you to assign different IP Profiles to specific users (calls) that belong to the same IP Group (User or Server type).

For example, you can configure two Classification rules to classify incoming calls to the same IP Group. However, one Classification rule is a regular rule that doesn't specify any IP Profile (IP Profile assigned to IP Group is used), while the second rule is configured with an additional matching characteristic for the source hostname prefix (e.g., "abcd.com") and with an additional action that assigns a different IP Profile.

By default, no value is defined.

Note: For User-type IP Groups, if a user is already registered with the device (from a previous, initial classification process), the device classifies subsequent INVITE requests from the user according to the device's users database instead of the Classification table. In such a scenario, the same IP Profile that was previously assigned to the user by the Classification table is also used (in other words, the device's users database stores the associated IP Profile).